One of the emerging communication technologies for delivering multimedia services across fixed and mobile access networks is the IP Multimedia Subsystem (IMS). The network architecture according to IMS comprises a service layer, control and connectivity layers, and an access layer. The control layer comprises call session control functions (CSCFs) forming central nodes for the provision of the SIP signaling (SIP: Session Initiation Protocol). The SIP protocol is one of the core technologies used by IMS for controlling the multimedia sessions combining voice and data streams.
A further core component of the IMS network architecture is the Service Capability Interaction Manager (SCIM) which was introduced in the 3GPP TS 23.002 standard as a function within a SIP Application Server domain of the IMS architecture. The role of the SCIM is that of a service broker in more complex service interaction scenarios which cannot be supported through the service filtering mechanism. The SCIM as proposed to the 3GPP uses an ISC interface to enable composite service behavior leveraging simpler service capabilities. In practical terms, a “capability” is a system component that may be used, presumably with other components, to implement a “service” that is packaged and delivered to end users of the network. For example, a group list server and a presence server may both be considered “capabilities” that are used to implement a sophisticated conferencing service. In this regard, an open issue in the 3GPP Release 9 specification is the orchestration of interaction between “capabilities” in the larger network which are represented as SIP Application Server instances.
SCIM can be implemented using service composition approach, where services, also called constituent services, may be aggregated to composite services. Composite services address complex user requirements that usually can not be covered by existing services. Hence, composite services offer added value in the form of new functionality compared to the sum of the functionality of their building blocks.
The service composition functionality usually introduces an entity—the service composition engine—that takes care of this complexity for the application. In this scenario the application implements just its core logic, whereas the enabling functionality such as the “location-based weather forecast” is exposed by the composition engine as a single service that may be easily discovered and bound by the application. In this case, the composition engine executes application logic in the form of the definition of the composite service “location-based weather forecast”. This composite service describes the type of required services, so that the engine—at run-time—may discover, bind and execute appropriate services. Composition functionality, consequently, allows for great flexibility e.g. in handling events such as a faulty enabler. In this case, the engine could bind an alternative service without any disruption of the end-user application.
Composition sessions resulting when executing composite services may contain session data. The session data are usually manipulated by the process according to instruction in its composite service description, i.e. according to a wish of a composite service designer. The data is either directly manipulated by these instructions, e.g. assigning a value to a variable, or indirectly, e.g. as results of services invocations. Sometimes, this kind of composition session state data is also called “Shared State Data”, because they represent the state shared between all services participating in a given composition session.
The composition session described above forms an embodiment of a distributed processing according to which different processes are executed on different entities. Further embodiments for distributed processing are a cloud computing scenario with a plurality of computing nodes or a processing arrangement with co-deployed processes which may even be executed within the same run-time environment.
Usually, distributed processes like the ones found in a composition engine operate on or require data such as input data for further processing. Therefore, all available data is provided towards the processes to ensure smooth processing. However, if the data to be exchanged is voluminous, then considerable network resources such as bandwidth or processing resources such as CPU load have to be reserved for data transmission. Furthermore, due to e.g. conditional processing branches, the respective process may not necessarily require all data associated with all possible conditional branches during process run-time, i.e. when the process is executed.
Therefore, there is a need for a more efficient data management in a distributed processing arrangement.